Устранение неполадок программно-определяемого сетевого стека Windows Server

  • Статья

В этом руководстве рассматриваются распространенные ошибки программно-определяемой сети (SDN) и сценарии сбоев, а также описывается рабочий процесс устранения неполадок, в котором используются доступные средства диагностики. Дополнительные сведения о SDN см. в разделе Программно-определяемые сети.

Применимо к: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, версии 21H2 и 20H2

Типы ошибок

В следующем списке представлен класс проблем, наиболее часто встречаемых с виртуализацией сети Hyper-V (HNVv1) в Windows Server 2012 R2 из производственных развертываний на рынке, и во многих отношениях совпадает с теми же проблемами, что и в Windows Server 2016 HNVv2 с новым стеком программно-определяемой сети (SDN).

Большинство ошибок можно классифицировать в небольшой набор классов:

  • Недопустимая или неподдерживаемая конфигурация

    Пользователь вызывает API NorthBound неправильно или с недопустимой политикой.

  • Ошибка в приложении политики

    Политика из сетевого контроллера не была доставлена на узел Hyper-V, отложена или не обновлена на всех узлах Hyper-V (например, после динамической миграции).

  • Смещение конфигурации или ошибка программного обеспечения

    Проблемы с пути к данным, приводящие к отброшенным пакетам.

  • Внешняя ошибка, связанная с оборудованием сетевого адаптера или драйверами или структурой подложной сети

    Неправильное выполнение разгрузки задач (например, VMQ) или неправильно настроенная структура сети (например, MTU)

    В этом руководстве по устранению неполадок рассматривается каждая из этих категорий ошибок и приводятся рекомендации и доступные средства диагностики для выявления и исправления ошибки.

Средства диагностики

Прежде чем обсуждать рабочие процессы устранения неполадок для каждого из этих типов ошибок, давайте рассмотрим доступные средства диагностики.

Чтобы использовать средства диагностики сетевого контроллера (путь к элементу управления), необходимо сначала установить RSAT-NetworkController компонент и импортировать NetworkControllerDiagnostics модуль:

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

Чтобы использовать средства диагностики HNV Diagnostics (data-path), необходимо импортировать HNVDiagnostics модуль:

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

диагностика сетевого контроллера

Эти командлеты описаны на сайте TechNet в командлете Диагностики сетевого контроллера. Они помогают выявлять проблемы с согласованностью политики сети в пути управления между узлами сетевого контроллера и между сетевым контроллером и агентами узла NC, работающими на узлах Hyper-V.

Debug-ServiceFabricNodeStatus Командлеты и Get-NetworkControllerReplica должны выполняться с одной из виртуальных машин узла сетевого контроллера. Все остальные командлеты диагностики NC можно запускать с любого узла, который имеет подключение к сетевому контроллеру и находится в группе безопасности управления сетевым контроллером (Kerberos) или имеет доступ к сертификату X.509 для управления сетевым контроллером.

Диагностика узла Hyper-V

Эти командлеты описаны в TechNet в командлете Hyper-V Network Virtualization (HNV) Diagnostics. Они помогают выявить проблемы в пути к данным между виртуальными машинами клиента (восток и запад) и входящего трафика через виртуальный ip-адрес SLB (север или юг).

, Debug-VirtualMachineQueueOperationGet-CustomerRoute, Get-PACAMapping, Get-ProviderAddressGet-VMNetworkAdapterPortId, Get-VMSwitchExternalPortIdи Test-EncapOverheadSettings — это все локальные тесты, которые можно выполнять с любого узла Hyper-V. Другие командлеты вызывают тесты пути к данным через сетевой контроллер и, следовательно, требуют доступа к сетевому контроллеру, как описано выше.

GitHub

Репозиторий GitHub Microsoft/SDN содержит множество примеров скриптов и рабочих процессов, которые создаются на основе этих встроенных командлетов. В частности, скрипты диагностики можно найти в папке Диагностика . Помогите нам внести свой вклад в эти сценарии, отправив запросы на вытягивание.

Устранение неполадок с рабочими процессами и руководствами

[Hoster] Проверка работоспособности системы

В нескольких ресурсах сетевого контроллера есть внедренный ресурс с именем Состояние конфигурации . Состояние конфигурации предоставляет сведения о работоспособности системы, включая согласованность между конфигурацией сетевого контроллера и фактическим (запущенным) состоянием на узлах Hyper-V.

Чтобы проверка состояние конфигурации, выполните следующую команду на любом узле Hyper-V с подключением к сетевому контроллеру.

Примечание.

Значением параметра NetworkController должно быть полное доменное имя или IP-адрес на основе имени субъекта сертификата X.509, >созданного для сетевого контроллера.

Параметр Credential необходимо указать только в том случае, если сетевой контроллер использует проверку подлинности Kerberos (как правило, в развертываниях VMM). Учетные данные должны быть для пользователя, который входит в группу безопасности управления сетевым контроллером.

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

Ниже показан пример сообщения о состоянии конфигурации:

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

Примечание.

В системе возникла ошибка, из-за которой ресурсы сетевого интерфейса для сетевой карты виртуальной машины SLB Mux Transit находятся в состоянии сбоя с ошибкой "Виртуальный коммутатор — узел не подключен к контроллеру". Эту ошибку можно спокойно игнорировать, если для IP-конфигурации в ресурсе сетевой карты виртуальной машины задан IP-адрес из пула IP-адресов транзитной логической сети.

Существует вторая ошибка в системе, из-за которой ресурсы сетевого интерфейса для сетевых карт поставщика HNV поставщика шлюза находятся в состоянии сбоя с ошибкой "Virtual Switch - PortBlocked". Эту ошибку также можно спокойно игнорировать, если ip-конфигурация в ресурсе сетевого адаптера виртуальной машины имеет значение NULL (по умолчанию).

В таблице ниже приведен список кодов ошибок, сообщений и дальнейших действий, которые необходимо выполнить на основе наблюдаемого состояния конфигурации.

Код Сообщение Действие
Unknown Неизвестная ошибка
HostUnreachable Главный компьютер недоступен Проверка сетевого подключения управления между сетевым контроллером и узлом
PAIpAddressExhausted ИСчерпали IP-адреса PA Увеличение размера пула IP-адресов поставщика HNV для логической подсети
PAMacAddressExhausted Адреса PA Mac исчерпаны Увеличение диапазона пула Mac
PAAddressConfigurationFailure Не удалось выполнить отсев pa-адресов к узлу Проверьте сетевое подключение управления между сетевым контроллером и узлом.
CertificateNotTrusted Сертификат не является доверенным Исправление сертификатов, используемых для связи с узлом.
CertificateNotAuthorized Сертификат не авторизован Исправление сертификатов, используемых для связи с узлом.
PolicyConfigurationFailureOnVfp Сбой при настройке политик VFP Это сбой среды выполнения. Никаких определенных обходных решений. Сбор журналов.
PolicyConfigurationFailure Сбой при отправке политик на узлы из-за сбоев связи или других ошибок в NetworkController. Никаких определенных действий. Это связано с сбоем при обработке состояния цели в модулях сетевого контроллера. Сбор журналов.
HostNotConnectedToController Узел еще не подключен к сетевому контроллеру Профиль порта не применяется к узлу или узел недоступен из сетевого контроллера. Убедитесь, что раздел реестра HostID соответствует идентификатору экземпляра ресурса сервера.
MultipleVfpEnabledSwitches На узле есть несколько коммутаторов с поддержкой VFp. Удалите один из коммутаторов, так как агент узла сетевого контроллера поддерживает только один виртуальный коммутатор с включенным расширением VFP.
PolicyConfigurationFailure Не удалось отправить политики виртуальной сети для vmNic из-за ошибок сертификата или ошибок подключения Проверьте, были ли развернуты правильные сертификаты (имя субъекта сертификата должно соответствовать полному доменному имени узла). Также проверьте подключение узла к сетевому контроллеру
PolicyConfigurationFailure Не удалось отправить политики vSwitch для виртуальной карты из-за ошибок сертификата или ошибок подключения Проверьте, были ли развернуты правильные сертификаты (имя субъекта сертификата должно соответствовать полному доменному имени узла). Также проверьте подключение узла к сетевому контроллеру
PolicyConfigurationFailure Не удалось отправить политики брандмауэра для виртуальной карты из-за ошибок сертификата или ошибок подключения Проверьте, были ли развернуты правильные сертификаты (имя субъекта сертификата должно соответствовать полному доменному имени узла). Также проверьте подключение узла к сетевому контроллеру
DistributedRouterConfigurationFailure Не удалось настроить параметры распределенного маршрутизатора на виртуальной карте узла Ошибка стека TCPIP. Может потребоваться очистка виртуальных сетевых интерфейсов узла PA и DR на сервере, на котором была зарегистрирована эта ошибка
DhcpAddressAllocationFailure Сбой выделения DHCP-адресов для виртуальной карты Проверьте, настроен ли атрибут статического IP-адреса в ресурсе сетевой карты.
CertificateNotTrusted
CertificateNotAuthorized		 Не удалось подключиться к Mux из-за ошибок сети или сертификата Проверьте числовой код, указанный в коде сообщения об ошибке: он соответствует коду ошибки winsock. Ошибки сертификата являются детализированными (например, сертификат не может быть проверен, сертификат не авторизован и т. д.).
HostUnreachable MUX неработоспособен (как правило, BGPRouter отключен) Одноранговый узел BGP на RRAS (виртуальная машина BGP) или коммутаторе Top-of-Rack (ToR) недоступен или пиринг недоступен. Проверьте параметры BGP для ресурса Программного Load Balancer Мультиплексора и однорангового узла BGP (виртуальная машина ToR или RRAS).
HostNotConnectedToController Агент узла SLB не подключен Убедитесь, что служба агента узла SLB запущена; Ознакомьтесь с журналами агента узла SLB (автоматическое выполнение) по причинам, по которым в случае отклонения сертификата, представленного состоянием запуска агента узла, в случае отклонения сертификата, представленного запущенным агентом узла, будут отображаться детализированные сведения.
PortBlocked Порт VFP заблокирован из-за отсутствия политик виртуальной сети и ACL. Проверьте наличие других ошибок, которые могут привести к тому, что политики не настроены.
Перегруженные Load balanceancer MUX перегружен Проблема с производительностью в MUX
RoutePublicationFailure Loadbalancer MUX не подключен к маршрутизатору BGP Убедитесь, что muX имеет подключение к маршрутизаторам BGP и правильно ли настроен пиринг BGP.
VirtualServerUnreachable Load balanceancer MUX не подключен к диспетчеру SLB Проверка подключения между SLBM и MUX
QosConfigurationFailure Не удалось настроить политики QOS Узнайте, доступна ли достаточная пропускная способность для всех виртуальных машин, если используется резервирование QOS

Проверка сетевого подключения между сетевым контроллером и узлом Hyper-V (служба агента узла NC)

Выполните приведенную netstat ниже команду, чтобы проверить, есть ли три ESTABLISHED подключения между агентом узла NC и узлами сетевого контроллера и один LISTENING сокет на узле Hyper-V.

  • ПРОСЛУШИВАНИЕ через порт TCP:6640 на узле Hyper-V (служба агента узла NC)
  • Два установленных подключения с IP-адреса узла Hyper-V через порт 6640 к IP-адресу узла NC на временных портах (> 32000)
  • Одно установленное подключение с IP-адреса узла Hyper-V на временном порту к REST IP-адресу сетевого контроллера через порт 6640

Примечание.

На узле Hyper-V могут быть только два установленных подключения, если на этом узле не развернуты виртуальные машины клиента.

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

Проверка служб агента узла

Сетевой контроллер взаимодействует с двумя службами агента узла на узлах Hyper-V: агентом узла SLB и агентом узла NC. Возможно, одна или обе из этих служб не запущены. Проверьте их состояние и перезапустите, если они не запущены.

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

Проверка работоспособности сетевого контроллера

Если три ESTABLISHED подключения отсутствуют или сетевой контроллер не отвечает, проверка, чтобы убедиться, что все узлы и модули службы запущены с помощью следующих командлетов.

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

Модули службы сетевого контроллера:

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • FirewallService
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

Убедитесь, что ReplicaStatus имеет значение , Ready а HealthState — Ok.

В рабочем развертывании с сетевым контроллером с несколькими узлами можно также проверка, на каком узле каждая служба является основным, и состояние его отдельных реплика.

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

Убедитесь, что состояние реплики готово для каждой службы.

Проверка соответствующих идентификаторов узлов и сертификатов между сетевым контроллером и каждым узлом Hyper-V

На узле Hyper-V выполните следующие командлеты, чтобы проверка, что идентификатор узла соответствует идентификатору экземпляра ресурса сервера в сетевом контроллере.

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

Исправления

При использовании скриптов SDNExpress или развертывания вручную обновите раздел HostId в реестре, чтобы он соответствовал идентификатору экземпляра ресурса сервера. Перезапустите агент узла сетевого контроллера на узле Hyper-V (физическом сервере) При использовании VMM удалите сервер Hyper-V из VMM и раздел реестра HostId. Затем снова добавьте сервер через VMM.

Убедитесь, что отпечатки сертификатов X.509, используемых узлом Hyper-V (имя узла будет именем субъекта сертификата) для связи (SouthBound) между узлом Hyper-V (служба агента узла NC) и сетевым контроллером, одинаковы. Кроме того, проверка, что сертификат REST сетевого CN=<FQDN or IP>контроллера имеет имя субъекта .

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

Вы также можете проверка следующие параметры каждого сертификата, чтобы убедиться, что имя субъекта соответствует ожидаемому (имя узла, полное доменное имя или IP-адрес REST NC), срок действия сертификата еще не истек и что все центры сертификации в цепочке сертификатов включены в доверенный корневой центр.

  • Имя субъекта
  • Срок действия
  • Доверенный корневой центр

Если несколько сертификатов имеют одинаковые имена субъекта на узле Hyper-V, агент узла сетевого контроллера случайным образом выберет один из них для представления сетевому контроллеру. Это может не соответствовать отпечатку ресурса сервера, известного сетевому контроллеру. В этом случае удалите один из сертификатов с тем же именем субъекта на узле Hyper-V, а затем перезапустите службу агента узла сетевого контроллера. Если подключение по-прежнему не удается создать, удалите другой сертификат с тем же именем субъекта на узле Hyper-V и соответствующий ресурс сервера в VMM. Затем повторно создайте ресурс сервера в VMM, который создаст новый сертификат X.509 и установит его на узле Hyper-V.

Проверка состояния конфигурации SLB

Состояние конфигурации SLB можно определить как часть выходных данных командлета Debug-NetworkController . Этот командлет также выведет текущий набор ресурсов сетевого контроллера в JSON-файлах, все IP-конфигурации с каждого узла (сервера) Hyper-V и политику локальной сети из таблиц базы данных агента узла.

По умолчанию будет собираться больше трассировок. Чтобы не собирать трассировки, добавьте -IncludeTraces:$false параметр .

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

Примечание.

Выходным расположением по умолчанию будет <каталог working_directory>\NCDiagnostics\. Выходной каталог по умолчанию можно изменить с помощью -OutputDirectory параметра .

Сведения о состоянии конфигурации SLB можно найти в файле диагностика-slbstateResults.Json в этом каталоге.

Этот JSON-файл можно разбить на следующие разделы:

  • Ткань
    • SlbmVips. В этом разделе перечислены IP-адреса ВИРТУАЛЬНОго IP-адреса диспетчера балансировки нагрузки, который используется сетевым контроллером для координации конфигурации и работоспособности между модулями SLB и агентами узла SLB.
    • MuxState — в этом разделе будет указано одно значение для каждого развернутого мультиплекса SLB, указывающее состояние мультиплекса.
    • Конфигурация маршрутизатора. В этом разделе перечислены номер автономной системы (ASN) вышестоящего маршрутизатора (одноранговый узел BGP), ip-адрес транзита и идентификатор. В нем также будут перечислены asn muxes SLB Muxes и IP-адрес транзита.
    • Сведения о подключенном узле. В этом разделе перечислены IP-адреса управления все узлы Hyper-V, доступные для выполнения рабочих нагрузок с балансировкой нагрузки.
    • Диапазоны виртуальных IP-адресов. В этом разделе перечислены диапазоны общедоступных и частных IP-адресов. IP-адрес SLBM будет включен в качестве выделенного IP-адреса из одного из этих диапазонов.
    • Маршруты mux. В этом разделе будет указано одно значение для каждого развернутого мультиплекса SLB, содержащего все объявления маршрутов для этого конкретного мультиплекса.
  • Tenant
    • VipConsolidatedState. В этом разделе будет указано состояние подключения для каждого виртуального виртуального ip-адреса клиента, включая объявленный префикс маршрута, узел Hyper-V и конечные точки DIP.

Примечание.

Состояние SLB можно определить непосредственно с помощью скрипта DumpSlbRestState , доступного в репозитории Microsoft SDN GitHub.

Проверка шлюза

Из сетевого контроллера:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

Из виртуальной машины шлюза:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

В верхней части стойки (ToR) переключатель:

sh ip bgp summary (for 3rd party BGP Routers)

Маршрутизатор Windows BGP:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Кроме того, из проблем, которые мы видели до сих пор (особенно в развертываниях на основе SDNExpress), наиболее распространенной причиной того, что отделение клиента не настраивается на виртуальных машинах GW, как представляется, заключается в том, что емкость GW в FabricConfig.psd1 меньше по сравнению с тем, что люди пытаются назначить сетевой Connections (туннели S2S) в TenantConfig.psd1. Это можно легко проверить, сравнив выходные данные следующих командлетов:

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Hoster] Проверка Data-Plane

После развертывания сетевого контроллера, создания виртуальных сетей и подсетей клиента, а также подключения виртуальных машин к виртуальным подсетям, хостер может выполнить дополнительные тесты на уровне структуры для проверка подключения клиента.

Проверка логического сетевого подключения поставщика HNV

После подключения первой гостевой виртуальной машины, работающей на узле Hyper-V, к виртуальной сети клиента сетевой контроллер назначит узлу Hyper-V два IP-адреса поставщика HNV (IP-адреса PA). Эти IP-адреса будут поступать из пула IP-адресов логической сети поставщика HNV и управляться сетевым контроллером. Чтобы узнать, что представляют собой эти два IP-адреса HNV, выполните следующие действия.

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

Эти IP-адреса поставщика HNV назначаются адаптерам Ethernet, созданным в отдельном сетевом отсеке TCPIP, и имеют имя адаптера VLANX , где X — это виртуальная локальная сеть, назначенная логической сети поставщика HNV (транспорт).

Подключение между двумя узлами Hyper-V с помощью логической сети поставщика HNV можно выполнить с помощью проверки связи с дополнительным параметром секции (-c Y), где Y — это сетевой отсек TCPIP, в котором создаются PAhostVNICs. Этот раздел можно определить, выполнив следующее:

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

Примечание.

Адаптеры vNIC узла PA не используются в пути к данным и поэтому не имеют IP-адреса, назначенного адаптеру vEthernet (PAhostVNic).

Например, предположим, что узлы Hyper-V 1 и 2 имеют IP-адреса поставщика HNV (PA):

Узел Hyper-V IP-адрес 1 IP-адрес PA 2
Узел 1 10.10.182.64 10.10.182.65
Узел 2 10.10.182.66 10.10.182.67

Чтобы проверка логического сетевого подключения поставщика HNV, мы можем выполнить связь между ними с помощью следующей команды.

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

Исправления

Если проверка связи с поставщиком HNV не работает, проверка физическое сетевое подключение, включая конфигурацию виртуальной локальной сети. Физические сетевые карты на каждом узле Hyper-V должны находиться в режиме магистрали без назначения определенной виртуальной локальной сети. Виртуальная сетевая карта узла управления должна быть изолирована в виртуальной локальной сети логической сети управления.

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

Проверка поддержки MTU и кадров jumbo в логической сети поставщика HNV

Другая распространенная проблема в логической сети поставщика HNV заключается в том, что физические сетевые порты и (или) Ethernet карта не имеют достаточно большого MTU, настроенного для обработки накладных расходов, связанных с инкапсуляцией VXLAN (или NVGRE).

Примечание.

Некоторые ethernet-карты и драйверы поддерживают новый *EncapOverhead ключевое слово который автоматически устанавливается агентом узла сетевого контроллера значение 160. Затем это значение будет добавлено к значению *JumboPacket ключевое слово, сумма которого используется в качестве объявленного MTU.

Например, *EncapOverhead = 160 и *JumboPacket = 1514 => MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

Чтобы проверить, поддерживает ли логическая сеть поставщика HNV больший размер MTU, используйте Test-LogicalNetworkSupportsJumboPacket командлет :

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

Исправления

  • Настройте размер MTU на портах физического коммутатора не менее 1674B (включая заголовок Ethernet и прицеп 14B).
  • Если карта сетевого адаптера не поддерживает ключевое слово EncapOverhead, измените ключевое слово JumboPacket как минимум на 1674B.

Проверка подключения к сетевой карте виртуальной машины клиента

Каждый сетевой адаптер виртуальной машины, назначенный гостевой виртуальной машине, имеет сопоставление CA-PA между частным адресом клиента (CA) и пространством адреса поставщика HNV (PA). Эти сопоставления хранятся в таблицах серверов OVSDB на каждом узле Hyper-V. Их можно найти, выполнив следующий командлет.

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

Примечание.

Если ожидаемые сопоставления CA-PA не отображаются для конкретной виртуальной машины клиента, с помощью командлета проверка ресурсы сетевой карты виртуальной машины и конфигурации IP-адресов в сетевом контроллереGet-NetworkControllerNetworkInterface. Кроме того, проверка установленные подключения между агентом узла NC и узлами сетевого контроллера.

С помощью этих сведений средство связи с виртуальной машиной клиента теперь может инициироваться хост-сервером из сетевого контроллера с помощью командлета Test-VirtualNetworkConnection .

Конкретные сценарии устранения неполадок

В следующих разделах приведены рекомендации по устранению неполадок в конкретных сценариях.

Отсутствие сетевого подключения между двумя виртуальными машинами клиента

  1. [Клиент] Убедитесь, что брандмауэр Windows на виртуальных машинах клиента не блокирует трафик.
  2. [Клиент] Убедитесь, что IP-адреса назначены виртуальной машине клиента, выполнив команду ipconfig.
  3. [Hoster] Запустите Test-VirtualNetworkConnection с узла Hyper-V, чтобы проверить подключение между двумя рассматриваемыми виртуальными машинами клиента.

Примечание.

VSID относится к идентификатору виртуальной подсети. В случае VXLAN это сетевой идентификатор VXLAN (VNI). Это значение можно найти, выполнив Get-PACAMapping командлет .

Пример

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

Создайте ca-ping между "зеленой веб-виртуальной машиной 1" с IP-адресом SenderCA 192.168.1.4 в узле "sa18n30-2.sa18.nttest.microsoft.com" с IP-адресом mgmt от 10.127.132.153 до IP-адрес listenerCA 192.168.1.5, подключенных к виртуальной подсети (VSID) 4114.

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[Клиент] Убедитесь, что в виртуальных подсетях или сетевых интерфейсах виртуальной машины нет политик распределенного брандмауэра, которые блокируют трафик.

Запросите REST API сетевого контроллера в демонстрационной среде по адресу sa18n30nc в домене sa18.nttest.microsoft.com.

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

Изучите конфигурацию IP-адресов и виртуальные подсети, которые ссылаются на этот список ACL.

  1. [Hoster] Запустите Get-ProviderAddress на обоих узлах Hyper-V, на которых размещены две виртуальные машины клиента, а затем запустите Test-LogicalNetworkConnection или ping -c <compartment> с узла Hyper-V, чтобы проверить подключение к логической сети поставщика HNV.
  2. [Hoster] Убедитесь, что параметры MTU заданы правильно на узлах Hyper-V и любых устройствах уровня 2, переключающихся между узлами Hyper-V. Запуск Test-EncapOverheadValue на всех указанных узлах Hyper-V. Кроме того, проверка, что для всех переключений уровня 2 для MTU задано не менее 1674 байт, чтобы учитывать максимальные затраты в 160 байт.
  3. [Hoster] Если IP-адреса PA отсутствуют и (или) подключение к ЦС не работает, проверка, чтобы убедиться, что политика сети получена. Выполните команду Get-PACAMapping , чтобы проверить, правильно ли установлены правила инкапсуляции и сопоставления CA-PA, необходимые для создания виртуальных сетей наложения.
  4. [Hoster] Убедитесь, что агент узла сетевого контроллера подключен к сетевому контроллеру. Для этого выполните команду netstat -anp tcp |findstr 6640.
  5. [Hoster] Убедитесь, что идентификатор узла в HKLM/ соответствует идентификатору экземпляра ресурсов сервера, на которых размещены виртуальные машины клиента.
  6. [Hoster] Убедитесь, что идентификатор профиля порта соответствует идентификатору экземпляра сетевых интерфейсов виртуальной машины виртуальных машин клиента.

Ведение журнала, трассировка и расширенные диагностика

В следующих разделах содержатся сведения о расширенных диагностика, ведении журнала и трассировке.

Централизованное ведение журнала сетевого контроллера

Сетевой контроллер может автоматически собирать журналы отладчика и хранить их в централизованном расположении. Сбор журналов можно включить при первом развертывании сетевого контроллера или в любое время позже. Журналы собираются из сетевого контроллера и сетевых элементов, управляемых сетевым контроллером: хост-компьютеров, программных подсистем балансировки нагрузки (SLB) и компьютеров шлюза.

Эти журналы включают журналы отладки для кластера сетевого контроллера, приложения сетевого контроллера, журналов шлюза, SLB, виртуальных сетей и распределенного брандмауэра. При добавлении нового узла, SLB или шлюза в сетевой контроллер на этих компьютерах запускается ведение журнала. Аналогичным образом, если узел, SLB или шлюз удаляется из сетевого контроллера, ведение журнала останавливается на этих компьютерах.

Включение ведения журнала

Ведение журнала включается автоматически при установке кластера сетевого контроллера с помощью командлета Install-NetworkControllerCluster . По умолчанию журналы собираются локально на узлах сетевого контроллера по адресу %systemdrive%\SDNDiagnostics. Рекомендуется изменить это расположение на удаленную общую папку (не локальную).

Журналы кластера сетевого контроллера хранятся в папке %programData%\Windows Fabric\log\Traces. Вы можете указать централизованное расположение для сбора журналов с DiagnosticLogLocation помощью параметра с рекомендацией, что это также удаленный файловый ресурс.

Если вы хотите ограничить доступ к этому расположению, можно указать учетные данные доступа с LogLocationCredential помощью параметра . Если предоставить учетные данные для доступа к расположению журнала, следует также указать CredentialEncryptionCertificate параметр , который используется для шифрования учетных данных, хранящихся локально на узлах сетевого контроллера.

При использовании параметров по умолчанию рекомендуется иметь не менее 75 ГБ свободного места в центральном расположении и 25 ГБ на локальных узлах (если не используется центральное расположение) для кластера сетевого контроллера с тремя узлами.

Изменение параметров ведения журнала

Параметры ведения журнала можно изменить в любое время с помощью командлета Set-NetworkControllerDiagnostic . Можно изменить следующие параметры:

  • Централизованное расположение журнала.

    Вы можете изменить расположение для хранения всех журналов с DiagnosticLogLocation помощью параметра .

  • Учетные данные для доступа к расположению журнала.

    Вы можете изменить учетные данные для доступа к расположению журнала с помощью LogLocationCredential параметра .

  • Перейдите к локальному ведению журнала.

    Если вы предоставили централизованное расположение для хранения журналов, вы можете вернуться к ведению журнала локально на узлах сетевого контроллера с параметром UseLocalLogLocation (не рекомендуется из-за требований к большому объему дискового пространства).

  • Ведение журнала область.

    По умолчанию собираются все журналы. Вы можете изменить область, чтобы собирать только журналы кластера сетевого контроллера.

  • Уровень ведения журнала.

    Уровень ведения журнала по умолчанию — Информационный. Его можно изменить на Error, Warning или Verbose.

  • Время хранения журнала.

    Журналы хранятся циклическим образом. По умолчанию у вас есть три дня для ведения журнала данных, независимо от того, используете ли вы локальное или централизованное ведение журнала. Это ограничение времени можно изменить с помощью LogTimeLimitInDays параметра .

  • Размер журнала старения.

    По умолчанию у вас будет не более 75 ГБ данных ведения журнала при использовании централизованного ведения журнала и 25 ГБ при использовании локального ведения журнала. Это ограничение можно изменить с помощью LogSizeLimitInMBs параметра .

Сбор журналов и трассировок

Развертывания VMM по умолчанию используют централизованное ведение журнала для сетевого контроллера. Расположение общей папки для этих журналов указывается при развертывании шаблона службы сетевого контроллера.

Если расположение файла не указано, локальное ведение журнала будет использоваться на каждом узле сетевого контроллера с журналами, сохраненными в папке C:\Windows\tracing\SDNDiagnostics. Эти журналы сохраняются в следующей иерархии:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Следы

Сетевой контроллер использует Service Fabric (Azure). При устранении определенных проблем могут потребоваться журналы Service Fabric. Эти журналы можно найти на каждом узле сетевого контроллера по адресу C:\ProgramData\Microsoft\Service Fabric.

Если пользователь запустил Debug-NetworkController командлет, на каждом узле Hyper-V будут доступны дополнительные журналы, указанные с ресурсом сервера в сетевом контроллере. Эти журналы (и трассировки, если они включены) хранятся в разделе C:\NCDiagnostics.

SLB диагностика

Ошибки структуры SLBM (действия поставщика услуг размещения)

  1. Убедитесь, что диспетчер программного обеспечения Load Balancer (SLBM) работает и что уровни оркестрации могут взаимодействовать друг с другом: SLBM —> SLB Mux и SLBM —> агенты узла SLB. Запустите DumpSlbRestState с любого узла с доступом к конечной точке REST сетевого контроллера.
  2. Проверьте SDNSLBMPerfCounters в PerfMon на одной из виртуальных машин узла сетевого контроллера (предпочтительно основной узел сетевого контроллера — Get-NetworkControllerReplica):
    1. Подключен ли двигатель Load Balancer (LB) к SLBM? (SLBM LBEngine Configurations Total > 0)
    2. Знает ли SLBM по крайней мере о своих конечных точках? (Всего >виртуальных ip-точек= 2)
    3. Подключены ли узлы Hyper-V (DIP) к SLBM? (подключенные клиенты HP == число серверов)
    4. Подключена ли SLBM к Muxes? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
  3. Убедитесь, что настроенный маршрутизатор BGP успешно выполняет пиринг с многомерным модулом SLB.
    1. При использовании RRAS с удаленным доступом (то есть виртуальной машиной BGP):
      1. Get-BgpPeer должно отображаться подключено.
      2. Get-BgpRouteInformation должен отображать по крайней мере маршрут для самостоятельного IP-адреса SLBM.
    2. Если в качестве однорангового узла BGP используется физический переключатель Top-of-Rack (ToR), обратитесь к документации:
      1. Пример: # show bgp instance
  4. Проверьте счетчики SlbMuxPerfCounters и SLBMUX в PerfMon на виртуальной машине SLB Mux.
  5. Проверьте состояние конфигурации и диапазоны виртуальных ip-адресов в ресурсе Диспетчер программного обеспечения Load Balancer.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8(проверка диапазоны ВИРТУАЛЬНЫх IP-адресов в пулах IP-адресов и убедитесь, что автономный IP-адрес SLBM (LoadBalanacerManagerIPAddress) и все виртуальные IP-адреса, доступные для клиента, находятся в пределах этих диапазонов)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

Если какая-либо из указанных выше проверок завершается ошибкой, состояние SLB клиента также будет находиться в режиме сбоя.

Исправления

На основе приведенных ниже диагностических сведений исправьте следующее:

  • Убедитесь, что мультиплексоры SLB подключены
    • Устранение проблем с сертификатом
    • Устранение проблем с сетевым подключением
  • Убедитесь, что сведения об пиринге BGP успешно настроены
  • Убедитесь, что идентификатор узла в реестре соответствует идентификатору экземпляра сервера в ресурсе сервера (справочное приложение для кода ошибки HostNotConnected )
  • Сбор журналов

Ошибки клиента SLBM (действия поставщика услуг размещения и клиента)

  1. [Hoster] Проверьте Debug-NetworkControllerConfigurationState , находятся ли какие-либо ресурсы LoadBalancer в состоянии ошибки. Попробуйте устранить эту проблему, следуя таблице элементов действий в приложении.
    1. Убедитесь, что конечная точка ВИРТУАЛЬНОго IP-адреса присутствует и рекламные маршруты.
    2. Проверьте, сколько конечных точек DIP было обнаружено для конечной точки ВИРТУАЛЬНОго IP-адреса.
  2. [Клиент] Проверьте, Load Balancer ресурсы указаны правильно.
    1. Убедитесь, что конечные точки DIP, зарегистрированные в SLBM, размещают виртуальные машины клиента, которые соответствуют IP-конфигурациям пула внутренних адресов LoadBalancer.
  3. [Hoster] Если конечные точки DIP не обнаружены или не подключены:

    1. Проверьте Debug-NetworkControllerConfigurationState

      Убедитесь, что агент узла NC и SLB успешно подключен к координатору событий сетевого контроллера с помощью netstat -anp tcp |findstr 6640).

    2. Regkey check HostIdin nchostagent service (reference HostNotConnected error code in the Appendix) соответствует идентификатору экземпляра соответствующего серверного ресурса (Get-NCServer |convertto-json -depth 8).

    3. Проверьте идентификатор профиля порта, чтобы порт виртуальной машины соответствовал идентификатору экземпляра ресурса сетевой карты соответствующей виртуальной машины.

  4. [Поставщик услуг размещения] Сбор журналов.

Трассировка SLB Mux

Сведения из программных Load Balancer Muxes также можно определить с помощью Просмотр событий.

  1. Выберите Показать журналы аналитики и отладки в меню Просмотр событий Вид.
  2. Перейдите в раздел Приложения и службы Журналы>Microsoft>Windows>SlbMuxDriver>Trace в Просмотр событий.
  3. Щелкните его правой кнопкой мыши и выберите Включить журнал.

Примечание.

Рекомендуется, чтобы это ведение журнала было включено только на короткое время, пока вы пытаетесь воспроизвести проблему.

Трассировка VFP и vSwitch

С любого узла Hyper-V, на котором размещена гостевая виртуальная машина, подключенная к виртуальной сети клиента, можно собрать трассировку VFP, чтобы определить, где могут возникнуть проблемы.

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes